今天是鐵人賽第 30 天。最近 Google 與 OpenAI 都推出會議助理，因此這篇選擇會議記錄這個具體功能，進行分析，以及整理結果如何接到後續工作。
一場會議結束，團隊通常還有兩件事要做：找出先前討論過的例外規則，以及把今天的決議整理成文件、交給負責人。逐字稿保存了談話，但這些工作仍然需要有人接手。
近期 OpenAI 推出 ChatGPT Meetings 外掛，Google 則推出 Google AI Edge Foresight。兩者都能協助記錄會議，但延伸方向不同：Meetings 把會議內容接到後續工作，Foresight 則把本機資料變成開會時能查詢的參考。
一般線上會議有兩個聲音來源：自己對著麥克風說話，以及電腦播放遠端參與者的聲音。Meetings 與 Foresight 都從 Mac 的麥克風及系統音訊取得內容，因此不必另外派一個 Bot 加入會議室。
這個設計把收音入口放在使用者的電腦。例如團隊在會議軟體討論改票，助理取得的是本機收錄的聲音；「不用 Bot」描述的是接入方式，不能據此判斷 AI 是否在本機運算。
真正的分岔發生在收音之後。加入開源 Meetily 作為參照，可以比較模型的部署位置、資料如何被利用，以及摘要之後能繼續做什麼。為了方便閱讀，以下將三個產品放在欄位，逐項對照：
| 比較項目 | Meetily Community | ChatGPT Meetings | Google AI Edge Foresight |
|---|---|---|---|
| 平台 | macOS、Windows；Linux 需自行建置 | macOS 桌面版 | Mac 桌面應用 |
| 技術架構 | Tauri＋Next.js 介面、Rust 音訊與模型處理、本機 SQLite | 桌面音訊入口＋OpenAI 雲端處理＋Space／Work；內部框架未公開 | 本機 AI 處理＋私人資料語意檢索；App 內部框架未公開 |
| 語音轉錄模型 | 本文分析本機 Whisper／Parakeet 路徑 | 具體模型未公開 | 具體模型未公開 |
| 本機 LLM | 支援 Ollama、BuiltInAI；也可選遠端摘要服務 | 非本機推論方案 | Gemma 4 |
| 轉錄與即時性 | 錄音期間分段推論，持續更新逐字稿 | 音訊串流上傳；筆記在處理完成後產生，文件未明確承諾即時逐字稿介面 | 會議中可利用當前談話補充筆記、回答問題；逐字稿更新粒度未公開 |
| RAG／跨會議查詢 | 本文主線未確認整合式跨會議 RAG | 可詢問已記錄會議，結合授權應用背景；檢索實作未公開 | 本機檢索逐字稿、筆記、文件與圖片，使用 EmbeddingGemma 2 |
| 摘要的輸入 | 逐字稿／中間摘要、模板與使用者補充 | 逐字稿、個人筆記、已授權應用的相關內容 | 當前談話與私人資料；檢索結果如何送入生成模型屬架構推論 |
| 會後工作 | 產生與保存摘要；本文路徑未包含外部任務執行 | 檢視、修改建議行動，再啟動 ChatGPT Work，例如草擬郵件或更新計畫 | 已公開重點是筆記補充與資料查詢，未確認同等外部任務執行流程 |
| 說話者辨識 | 未保存說話者 ID | Meetings 專屬文件未明確確認 | 本文引用的官方文件未明確確認 |
| 離線與資料邊界 | 轉錄與摘要都選本機服務時，可留在本機；遠端 Provider 會改變資料流向 | 需雲端處理，離線時音訊可能暫存等待上傳 | 官方說明可完全本機、離線處理 |
| 授權／取得方式 | Community 程式碼 MIT；模型授權另計，Pro 為另一版本 | 專有服務；Pro、Business Beta，Enterprise 限定 Alpha | 實驗性應用，無雲端訂閱費；引用資料未提供 App 開源授權，不能套用底層模型的授權 |
備註：「未確認」表示證據不足，不能直接解讀成不支援；能詢問歷史會議，也不代表已公開 RAG 的向量資料庫或排序機制。
Meetings 的處理材料包含逐字稿、使用者自己的筆記，以及已授權連接應用中的相關內容。它據此整理摘要與建議行動，使用者可在會議頁面檢視、修改，再啟動行動，交由 ChatGPT Work 處理。
它有明確的三個階段操作流程：
| 步驟 | 使用者操作 | 介面與結果 |
|---|---|---|
| 1. 開啟會議功能 | 從 ChatGPT 桌面版側邊欄開啟 Meetings | 進入會議功能 |
| 2. 開始記錄 | 點選 Take notes | 開始記錄；使用者也能在會議頁面自行補充筆記 |
| 3. 結束記錄 | 停止記錄，等待處理 | 同一個會議頁面加入個人化摘要與建議行動，保留手寫筆記 |
| 4. 調整建議 | 逐項檢視、編輯建議行動 | 把準備交給 ChatGPT 的工作內容改清楚 |
| 5. 啟動工作 | 一鍵啟動選定的行動 | 交給 ChatGPT 處理，例如草擬郵件或更新專案計畫 |
以退款例子來說：
| 階段 | 內容示例 |
|---|---|
| 會議中說的話 | 「小林，請你向主管確認這筆退款能不能適用例外，週五前回覆。」 |
| 摘要中的待辦 | 「小林於週五前向主管確認退款例外是否適用。」 |
| 可啟動的行動建議 | 「草擬一封向主管確認退款例外的郵件。」 |
| 使用者編輯後 | 「草擬確認信，附上申請原因與目前規則，請主管確認是否適用例外；只產生草稿。」 |
| 啟動後期待的成果 | 一封可以檢查、修改的郵件草稿，而不只是摘要裡的一條待辦 |
最後的郵件草稿可能是：
主旨：請確認本次退款申請是否適用例外
主管您好，本次申請涉及退款例外，想請您確認是否可依例外程序處理。以下整理申請原因與目前規則……再請於週五前回覆，以利後續作業。
這裡的產品特色就很明確：會議頁面上的建議行動可以被編輯並直接啟動，讓使用者從「知道要做什麼」接著走到「產生工作成果」。
資料保存另有一個限制：官方表示，筆記完成後會刪除 Mac 與伺服器上的音訊，無法重播。[1] 若工作要求保留原始錄音供日後核對，就不能只把這項功能當作錄音封存系統。
Foresight 著重當下的資訊取得。Google 公布的情境包括用會議內容補充簡短筆記，以及透過自然語言搜尋文件、圖片、逐字稿與筆記；Foresight 將納入知識庫的不同類型內容轉為可比較的語意表示，在本機檢索，再支援問答與筆記整理。
它採用的 EmbeddingGemma 2 是向量模型。向量的用途，是讓系統比較內容與問題在語意上是否接近；Google 的 Universal Embedder 文件明確把輸出定義為 EmbeddingResult，其中包含特徵向量，並提供相似度比較功能。
依公開模型與功能，合理的分工推論是：EmbeddingGemma 2 將問題與資料轉成向量，檢索層挑出相關片段，再把片段與當前語境交給 Gemma 4 組織答案或補充筆記。
以 Google 公開的模型與 Semantic Retriever SDK 來理解，這類功能可以拆成以下流程。這是可參考的實作架構，並非 Foresight 已公開的完整內部設計：
| 階段 | 具體處理 | 與你的問題的關係 |
|---|---|---|
| 安裝與初始化 | 準備程式、模型權重與推論引擎 | 模型安裝完成，不代表已經讀過你的文件 |
| 資料加入 | 應用程式取得要搜尋的文字、圖片等內容；長文字切成片段 | 必須先決定索引哪些資料，沒有必要涵蓋整台電腦 |
| 建立索引 | 用 embedding 模型產生向量，保存向量、來源與相關 metadata | 向量是供搜尋使用的表示，不是重新訓練模型 |
| 執行搜尋 | 把使用者問題轉成向量，找出最相近的資料片段 | 通常不必每次搜尋都重新處理所有原始文件 |
| 生成回答 | 如需回答或整理筆記，再把取回的內容交給生成模型 | 「找資料」和「根據資料寫答案」可以由不同模型分工 |
Google 的 Semantic Retriever 文件公開了資料加入、文字切分、向量儲存與相似度檢索等能力。
例如，假設一個應用程式只將「專案 A」資料夾納入索引，就能搜尋其中的企劃書和圖片；「專案 B」若沒有加入，也沒有其他搜尋管道，就不會因為模型已安裝而自動變得可搜尋。這是架構示例，並非已確認的 Foresight 資料夾設定方式。
假設本機已有一份退款 SOP，會議中有人問：「天候造成取消，可以免手續費嗎？」這類檢索增強生成（RAG）設計可拆成三個職責：
整理結果的後續用途，也與 Meetings 不同。Foresight 已公布的是把談話與私人資料用於筆記補充、搜尋與會議中問答；本文沒有找到它將摘要轉成外部任務、替使用者更新專案或寄送郵件的官方依據。因此，能分析的是「資料如何成為可查詢的背景」，不能再推導成已具備工作執行 Agent。
如果想看可追查的會議助理實作，可以參考 Meetily。它以 Tauri 組成桌面應用，Next.js 負責介面，Rust 負責音訊處理、模型呼叫與本機 SQLite 儲存。以下依本文查核的 Community 主線程式碼說明，不代表 Foresight 採用相同實作。
它將模型工作分成兩段：
audio/pipeline.rs 先混音，透過語音活動偵測（VAD）切出語音片段，再由 audio/transcription/worker.rs 交給選定的 Whisper 或 Parakeet 引擎。模型收到音訊取樣，回傳文字，worker 再以 transcript-update 事件更新逐字稿。summary/processor.rs 將逐字稿、模板與使用者補充組成文字請求，再由 summary/llm_client.rs 呼叫摘要模型。Ollama 與 BuiltInAI 路徑遇到超過門檻的長文時，會先分段摘要，再合併成報告。這個分工表示，更換摘要模型不會同時更換語音辨識模型。例如使用本機 Whisper 轉錄後，可以交給本機 Ollama 整理決議；如果摘要改用雲端 Provider，文字就會送到對應服務，因此本機轉錄不等於整個流程都在本機。
iThome鐵人賽
看影片追技術